Log Monitoring

Logging information from your Keyfactor Command implementation is available in a variety of places:

• Dedicated text files for each application are written to the server (e.g. the logs for the various components of Keyfactor Command are saved, by default, under the local folder: C:\Keyfactor\logs\...). See Editing NLog.
• The Windows event log on the Keyfactor Command server. See Keyfactor Command Windows Event IDs.
• The Audit Log in the Keyfactor Command Management Portal: Logs of auditable changes that affect your Keyfactor Command implementation—e.g. creation, change, or deletion of a record in an area of the product such as Certificates or Security—are viewable in the Management Portal, are output to a text file on the Keyfactor Command server, and can optionally be collected to a separate server for analysis with a centralized logging solution. See Audit Log.

In addition, transactions coming into the Keyfactor Command Management Portal are written into the IIS logs. For the most part, there is no need to look in the IIS logs unless you encounter a problem you need to troubleshoot. However, it is a good practice to monitor the text logs, the audit log, and the Windows event logs to make sure the system is operating smoothly and no errors are occurring.

By default, 10 main text logs are retained before the oldest ones are automatically deleted. Logs are rotated daily or when they reach a maximum file size, whichever comes first. Depending on the volume of log information you're generating, 10 logs may cover 10 days or a much shorter period. If you're using a centralized logging solution that runs daily to copy these to another location for analysis, the default log configuration of 10 logs with a maximum file size of 50 MB may be a sufficient retention policy. If you intend to analyze them in place on the Keyfactor Command server, you may wish to extend this retention setting.

In both the text-based logs and the Windows event logs, errors will generally appear with a tag of Error. For the text log, an error entry would look something like this, with more information following this line (and perhaps before it) with some further details:

Some errors may be transitory. For example, a CA A certificate authority (CA) is an entity that issues digital certificates. Within Keyfactor Command, a CA may be a Microsoft CA or a Keyfactor gateway to a cloud-based or remote CA. synchronization may fail because a CA was down for maintenance and then succeed on the next try when the server is back up. If you find errors in your logs and need help tracking down their cause, contact Keyfactor support (support@keyfactor.com).

When troubleshooting an error, it may be helpful to turn up the logging level in the Nlog.config file relevant to the component of interest to debug or trace. However, this can result in a large volume of messages that can be hard to wade through. It is sometimes useful to add further filters to the Nlog.config file relevant to the component of interest to filter out log traffic unrelated to the error you are trying to investigate. Some of the NLog files for the various log components contain pre-defined filters such as:

These filter out messages that contain the referenced string (e.g. WebSecurityContext) at the end of the log source string (e.g. CSS.CMS.Web.Security.WebSecurityContext) but only for messages that are at an Info, Debug or Trace level (less than Warn) as in this log line:

You can add more lines like this that do things like filter out the periodic report cleanup process, for example:

You can also filter out messages based on all or part of the message. Say you want to look at CA synchronization messages, but want to eliminate some of the chatter related to that. You don't want to filter out all the CA synchronization source messages in that case, but you might choose to get rid of entries like this:

You can do that with a filter that looks like this:

Some informational, warning, and error messages generated by Keyfactor Command are coded in a manner to allow them to be redirected for output to the Windows Application event log. If you redirect these messages from being output to the event log to a file instead, they look something like:

The -EVENT tag (highlighted in red, above) is what codes these messages for redirection to the event log. There are two configuration lines in the NLog.config files for the various log components that relate to Windows event log redirection—the first formats the data correctly for event log usage and assigns a source to the messages while the second captures all the messages coded -EVENT, prevents them from going to the regular text log, and redirects them to the event log for all messages at info, warning or error level. Debug and trace level messages are not designed to be output to the event log. To reduce the volume of messages to the event log, you can change minlevel="Info" to minlevel="Warn" or minlevel="Error". Be aware that if you do this, more verbose messages (e.g. info level messages) will fall through to the text-based log.

By default, messages redirected to the event log are marked with a source of Keyfactor Command for Keyfactor Command server, Keyfactor Service for the Keyfactor Command Service, and Keyfactor Orchestrators or Keyfactor Orchestrator for the Keyfactor Universal Orchestrator The Keyfactor Universal Orchestrator, one of Keyfactor's suite of orchestrators, is used to interact with Windows servers (a.k.a. IIS certificate stores) and FTP capable devices for certificate management, run SSL discovery and management tasks, and manage synchronization of certificate authorities in remote forests. With the addition of custom extensions, it can run custom jobs to provide certificate management capabilities on a variety of platforms and devices (e.g. F5 devices, NetScaler devices, Amazon Web Services (AWS) resources) and execute tasks outside the standard list of certificate management functions. It runs on either Windows or Linux. and Keyfactor Windows Orchestrator The Windows Orchestrator, one of Keyfactor's suite of orchestrators, is used to manage synchronization of certificate authorities in remote forests, run SSL discovery and management tasks, and interact with Windows servers as well as F5 devices, NetScaler devices, Amazon Web Services (AWS) resources, and FTP capable devices, for certificate management. In addition, the AnyAgent capability of the Windows Orchestrator allows it to be extended to create custom certificate store types and management capabilities regardless of source platform or location..